Thanks camarade. Can you fix tests?

Fix typo https://github.com/SpikeInterface/probeinterface/actions/runs/27208057889/job/80329128446?pr=446 and pre-commit?

[Edit] I decided to move the biggest point I made here into its own issue (#447), as I think it is more or less orthogonal to this PR.

Now regarding this PR. The idea of having a way of preserving the order through to_numpy/from_numpy and to_dict/from_dict, and giving the JSON file a defined display order, seems reasonable to me. More importantly, _global_contact_order seems like a fine internal lever for it. I read it as an implementation detail we can set and apply internally in whatever scenario needs it, without changing the public surface, and I think this is a good idea because it frees device_channel_indices from this burden.

Some small comments:

• global_contact_order.to_list() should be .tolist() (it is annoying that pandas and numpy are different in this regard.)
• the docstring of set_global_device_channel_indices still refers to the old channels parameter after the rename to device_channel_indices.
• The annotation metadata should be fixed first; let's not leave this as a TODO. Unless we move towards Add dense-array-base representation handle to ProbeGroup #425, we should fix this here as this will keep causing metadata propagation errors on SpikeInterface (#4545, #4546, #4547).

One big problem that I would like to point out, but which I think is bigger than this PR: get_slice suffers from the same array-based confusion I have been arguing against, its arguments are positional integers. Rather than litigate it here and gate this PR on it, I have moved it to its own issue: #447. The short version is that the public API should select contacts by stable identifiers (contact_ids) rather than positional integers, which would also make the annotation/metadata problem above disappear. My objection is specifically that the public API should remove its array-like components; keeping the order internally, as _global_contact_order does, is fine. So the serialization work in this PR can proceed independently of that discussion.

A clarification. I don't think my PR #425 here in probeinterface is superseded by this. Not that I am attached to keeping it, but to be clear: that PR is about providing a small dense representation so people can index on it in an array-like way to fetch properties. That is the full goal of it. In a nutshell, the full numpy representation is too much; let's provide a small surface area, commensurate with what SpikeInterface needs, that achieves that goal.